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FOBEUOBD 


The purpose of the Functional Design Specification 
(FDS) is to outline the design for the Problem Data System. 
The Problem Data System is a computer-based data management 
system designed to track the status of problems and 
corrective actions pertinent to Shuttle hardvare. 

J 

This FDS is an extension of the Detail Requirements 
Document and as a result is not intended as a stand-alone 
document. 
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GLOSSARY 

CFE Contractor Furnished Equipment 

Equipment vhlch is provided to NASA by a prime 
contractor. 

DRO Detailed Requirements Document 

PDS Functional Design Specifications 

6PB Government Furnished Equipment 

Equipment which is procured or manufactured by JSC or 
other NASA centers. 

IPDS Interim Problem Data System 

JSC Lyndon B. Johnson space Center 

LEC Lockheed Electronics Company, Inc. 

PAE Problem Assessment Engineering 

Responsible for permanent storage and retrieval of 
data pertaining to problems occurring on hardware 
programs. PAE also defines procedures for processing 
of information resulting from these problems. 

PDS Problem Reporting Data System 

A computer-based system for tracking the status of 
problems and corrective actions related to Shuttle 
hardware. 


GLOSSARY (Concluded) 


QAD Quality Assurance Division 

Responsible for management of the Problem Reporting 
Analysis and Corrective Action (PRACA) System, and 
Resolution of Manufacturing problems. 

SRSQA Safety, Reliability and Quality Assurance Office 

S2K System 2000 

General purpose data management system which provides 
access to one or more data bases. 

• 1 

S2KNN System 2000 multi-user multi-thread 

Kxecutive to allow concurrent update access to data 

I 

bases. 


TLP 


Task Link Processor 
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1,0 GENfBRAL 


I i 

1.1 IDENTIFICATION 


This Functional Design Specification (FDS) has been 
prepared for the Lyndon B. Johnson Space Center (JSC ) , 
Institutional Data Systems Division (IDSD) , by the Shuttle 
Information Management Systems Department of Lockheed 
Electronics Company, Inc^ (LEG) in response to support 
contractor job order 80-099, Problem Data System (reference 
1) and in accordance with the Task Description for the 
Problem Data System (reference 2) . The Problem Data System 
(PDS) is being developed for the Quality Assurance Division 
(Safety, Reliability and Quality Assurance Office) . 

1.2 PURPOSE 


The PDS will provide the user organizations with an 
integrated management and documentation tool to support the 
following functions: 






• Interactive tracking of Shuttle Hardware problem 
status and corrective action 

• Online updates 

• Data searches and code transformations 

• Display of data in predefined reports 

• Batch reports 
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1.3 BACKGROUND AND REFERENCES 


Prior to the implementation of the final PDS an Interim 
Problem Data System (IPDS) was established. IPDS 
accomplished two ma'or objectives: the storage of problem 

data in machine readable form for eventual transfer to PDS 
and the production of a:, weekly open Problem List. In 
addition, it provides a full problem listing batch report 
and responds to certain online requests. IPDS was 
implemented in February 1975 on the CYBER computer, under 
the KRONOS Tine Sharing^ Operating System (KRONOS) , and 
utilizing SYSTEM 2000 (S2K) as the data management system 
software. 

Additional background information is provided in the 
DRD for PDS. 

1.4 DESIGN CONSTRAINTS 

The Problem Data System will utilize the JSC CYBER 74 
computer system. PDS will require shared usage of the 
following hardware: 

• CYBER 74 computer 

• CDC 844 disk mass storage 

• Hazeltine 4000G (JSC MOPS) 

• High speed line printer 

The PDS resides with and operates using the following 
software: 

• KRONOS CYBER operating system 
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• TCS Terminal Control System 

• Common Software SPINS applications shared routines 

• System 2000 Data Base management system 

The system requires both online interaction and batch 
processing. 

1.5 SYSTEM INT£RFhCE 

The Problem Data System data base will initially be 
loaded from the IPDS data base currently operating on the 
JSC CYBER 74 computer. This interface is described in 
detail in section 5 . 1r Data Base Establishment. 


2 • 0 S Y ST EM_DES IG N 


2.1 SYSTEM ARCHITECTURE 

The PDS is designed to operate on the JSC CYBER 70 
series computer as t«o independent systems; the interactive 
processing system » and the batch processing system. In 
support of these two systems there will be three data bases 
and three permanent files (defined later in this document). 

I 

The interactive system interfac^'es to the user via his 
terminal and to the three data bases by means of S2KMM. The 
three permanent files are updated by the interactive system 
during transaction processing. 

The batch system interfaces to two of the data bases by 
means of S2K (single-user update) and to the user by a card 
reader. The three permanent files are used as input for 
report generation. 

Figure 2-1 illustrates the basic high level PDS flow. 

2.1.1 Design Approach 

The PDS interactive system will use transaction 
processing techniques. A transaction is the process by 
which an interactive system directs a programmed function to 
a predetermined conclusion. A transaction includes the 
input message, the computer processing and the sending of 
output messages associated with the function. Additional 
terminal and mass storage I/O, under program control, may be 
required to fulfill the initial user request. Terminal 
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support will utilize a structured mode for input and output 
of data (Forms) . The transaction is terminated fay the final 
output messages for the function initiated by a users 
request or by user interruptions. 

A transaction will be processed by the serial execution 
of a chain of tasks. A task is a logical subset of a 
transaction. The functions supported by the tasks to be 
prowided are: 


Unique Number of 

Task Name , Task s. R equire d , £iia£ii 2 Iiai-&®scri£tiQa 


User Validation 1 


User Termination 1 


Command Cracker 1 


Input 20 

(interactive) 


Receives user number 
and password and vali~ 
dates request against 
the security data base. 
Establishes user access 
to Problem Data Base, 
and initiates command 
cracker. 

Closes all data bases; 
process valid trans- 
action, table and sta- 
tistics loggipg. 

Interprets function key 
or command and initial- 
izes first task of the 
requested transaction. 

Receive from the user 
all selection criteria 
necessary to process 
the requested trans- 
action. Initiates next 
task in the trans- 
action. 


2-3 


T as k Name 


Unique Number of 

gunct io na l De scription 


Read Data Base 


38 


Security 


15 


Write terminal 38 

(structured) 


Read Terminal 15 

(structured) 


Validation 13 


Write Data Base 


20 


Selects proper data 
base and reads data re-* 
quired to execute 
transaction. 

Determines if user is 
allowed access to data 
and/or authority to ex- 
ecute transaction. 

.Initialize forms and 
provide data to common 
software routines for 
transmission to user 
terminal . 

Receive data transmis- 
sion from user utiliz- 
ing common software and 
reformating input data 
as required. 

Editing of input data 
utilizing code list 
from mass storage and 
common software. This 
task will also provide 
code conversion. 

Updating applicable 
data base. 


The unique exception processing (input error, user 
interrupt) support required by each task will be defined in 
the detail design of each task. ?]xception processing will 
provide two capabilities: 

• Initiation of command transaction (user interrupt) 

• Initiation of error correction (input error) 


V. 
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The linkage of the tasks to fora a transaction is 
accomplished by the use of the Task Link Processor (TLP) in 
PDS, The TLP is a program that calls the next task in a 
transaction’s sequence. The Task Link Processor makes no 
decisions; however, each task is responsible for scheduling 
the next task through the TLP. The Task Link Processor 
calls the Sign-On transaction. 

Communications between tasks is provided via a common 
communication area. Bach element in the communication area 
will be defined. Data can be passed between tasks in an 
orderly fashion using this technique. 

The transactions necessary to satisfy the requirements 
of the PDS DED are illustrated in figure 2-2, Each 
transaction is outlined in section 3 of this document. 

The PDS batch processing system is designed to operate 
in a multi-programming environment producing the reports 
that were outlined in the DRD for PDS. Figure 2-3 
illustrates the high level batch processing system. Section 
4 of this document outlines each of the batch programs. 

2.1.2 Common Software 

The SPIMS Common Software was conceived as a method for 
minimizing development and maintenance cost of the SPIMS 
applications while reducing the time-frame of their 
development. The PDS will make use of the SPIMS Common 
Software routines as described in the Common Software 
Detailed Requirements Document and Functional Design 
Specifications (reference 9 and 10). 


TASK LINK 
FROCESSOR 




• 









■ 


OCMDMICATIOH AREA 












"T 

1 - 

1 

1 

Steadard 

ProblcB 

Display 


» 

Standard 
Pxeblen 
Aid - Page 1 


» 

Standard 

Problea 

Add - Page 2 


Standard 
Problea 
Add - Page 3 



- -1- 

Standard 
Probleas Up- 
date - Page ] 


^ as 

Standard 
Problem Up- 
date — Page 2 


Standard 
Problea Up- 
date - Page 3 


Express 

Problea 

Display 






1 

1 

1 




■n 

1 

Express 
Problea 
Add - Page I 


Express 
Problea 
Aid - Page 2 


1 

Express 
Problea 
Add — Page 3 


1 

Express 
Problea Up- 
date - Page 1 



Express < 
Problea Dp- I 
date - Page 2 I 


Express 
Problea Up- 
date - Page 3 


Code List 

Table 

Display 


Code List 

Eleaent 

Display 













1 

Code List 

Elesmt 

Add 


1 

Code List 

Elenent 

Update 


^ i 1, 1 ■ 

Abbreviated 

Problea 

Display 


1 

Eleaent 

Display 



» 1 
Eleaent 
Update 


Standard 
Problea Iden- 
tification 


Express 

Problea 

Identlflcatioi 


Hardware 

Identifica- 

tion 













• 1 

p , J 1 

Problesi 

Bffectivlty 


Problea 

Description 


* 1 
Standard 
Pertinent 
Docuaent 


^ ■ I 

Express 

Pertinent 

DoctSKnt 



Reaarks 

Division 


Analysis 

Division 

' 

Besolutlon 

Division 


PAE 

Problem 

Keview 








— ' 1 



1 

— : 1 

Open 

Froblea 


Snbsystea 

Problea 


1 

Action 
Assignee - 


■- 1 

r Action 
Assignee - 



Part 

)tuid)er 


Part 

Natte 


Problea 

Delete 


Problea 

Reassignment 

Soasary 




Open 


1 Closed 



Searches 


Indices 












1 


1 

1 



p- -1 

Add 

Passim rd 


» 

Change 

PasBvord 


Delete 

Passvord 


Sign-On 


P* * ^ 

Sign-Off 


Cosaind 



INTERACTIVE PROCESSING SYSTEM 
Figure 2-2 























2-7 







since ComaoQ Software will be provided as a series of 
subroutines callable iron PDS tasks, the user will 
coBBunicate with a coapletely integrated package. The use 
of CoBBon Software will therefore be transparent to the 
user. 


CoBBon software will provide the following routines. 

• TerBinal Interface routines 

• Data Element Editing routines 

• Utility routines 

The TerBinal Interface routines will provide the data 
paths and interfaces to coBBunica te with the user terainals. 

The Data Element Editing routines provided by coBBon 
software will be supplewented by additional PDS routines to 
provide the editing required by PDS. 

The utility routines provided by common software will 
include string Packages and File Input/Output routines. 

These will be used instead of standard FOBTBAN in order to 
conserve central neBory. 

2.1.3 System 2000 

System 2000 is the general purpose data base manager to 
be used by PDS. A detailed description of System 2000 is 
provided by reference 11, 

System 2000 multi-user, update feature will be utilized 
to allow concurrent access to the data bases during 


interactive processing. The single-user update version of 
Systea 2000 will be used for the batch processing. 

PDS will use the Basic Natural Language feature to 
define the data bases. Natural Language will also be 
eaployed by the data base adninlstrator to provide data base 
backup. 

FORTRAN language subroutines will utilize the 
Procedural Language Interface (PLI) feature to manipulate 
data in the System 206o data bases. This feature will be 
utilized in both the interactive processing and the batch 
processing. ' 

2.2 FILE DEFINITION 

The following files will be utilized or generated by 
the PDS system. 

• System 2000 Data Base - a set of six associated 
direct access files, with an associated update file. 
These are the standard files S2K creates when a data 
base is defined. 

• Permanent files - created during the execution of 
the interactive system. These files are for valid 
transaction logging, table logging and statistic 
recording. Figure 2-4 illustrates the record format 
of these files. 


2-10 



VALIb TRAKSM1T\0W FILE 



TABLE 1WSACTle>^ FILE 


USAGE .STATISriCS FILE 

'f€r?H^K'e^fT i^iijg 16(^1^ f^mT3 

■ Z'H- 





2.3 DATA BA.SE DEFINITION 


The PDS will consist of three unique data bases 
(Problem, Tables, Security) . The information contained in 
each data base relates to the transaction/task concept of 
the PDS. A transaction requesting data from the Problem 
Data Base does not conflict with a transaction requesting 
data from the Tables Data Base. Hot only does this speed up 
processing by reducing the data base queue but also reduces 
search time by sinplifing the data base structures. 

2. 3. 1 Problem Data Base 

The Problem Data Base is used to maintain the problem 
data for PDS. It will be used by the read data base and the 
write data base tasks during the execution of a problem 
related transaction. This data base will also be used by 
the batch programs to produce the Open problem List and Full 
Problem Report. 

The Problem Data Base is a two level structure. Level 
0 contains the heading and problem identification 
information for each entry. Standard abbreviations are 
stored along with express codes for some elements to reduce 
processing time upon display of the data. Level 1 contains 
the remaining information for each entry broken up into 
seven repeating groups. The first three repeating groups 
contain data which is repetitive in nature and can appear 
■any times per entry. Location of this information in its 
own repeating group facilitates system retrieval time and 
ninimizes mass storage. The last four repeating groups are 
text fields and are defined such that a line of text is a 


I 


data eleaent. This implied cepetitive pattern indicates 
repeating group structure for the sane reasons given above. 

Figure 2*5 illustrates the structure of the Problea 
Data Base. 

2.3.2 Tables Data Base 

The Tables Data Base is used to maintain the data 
validation tables for POS. A Common Software program will 
be executed at system startup time to collect the various 
tables into a single random access file. PDS will utilize 
this file for data validation processing. Also the Tables 
Data Base will be used during a table change transaction. 

The Tables Data Base is a two*leyel data base. Level 0 
contains the table name and codes. Level 1 contains the 
entries for each table. 

Figure 2*6 illustrates the structure of the Tables Data 
Base. '' 

2.3.3 Security Data Base 

The Security Data Base is used to maintain the user 
passwords for PDS. It will be used by the sign*On 
Transaction to verify PDS users. It will also be used by 
the Password-dependent transactions (Add, Change, Delete) . 

The Security 'Data Base is a one-level data base. The 
Data Base will contain the user ID, user password, and the 
infornation to determine Problea Data Base access. 



) 
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Figure 2-7 illustrates the structure of the Security 
Data Base. 
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3.0 INTERACTIVE PROCESSING SYSTEM 


The establishment of the transaction oriented link 
between a user and PDS requires the execution of certain 
unique transactions. ; The following transactions are 
initiated by PDS whenever a user requests access to the 
system or finishes his job session. 

• Sign-On 

• Processing request (establishes control mode for 
interactive processing) 

• Sign-Off 

The functions performed by these transactions are: 

• User identification (Sign-On) 

• User Control Mode (Command) 

• User Termination (Sign-Off) 

These transactions are discussed in detail in sections 
3.13, 3.14, and 3.15 respectively. 

The transaction interactions required to satisfy an 
interactive processing request are described in Sections 3.1 
through 3.12. 

Function keys on the JSC MOPS terminals will be used to 
select the transaction the user wishes to process. The 
function key will indicate the user’s control mode. 

The PDS DRD paragraph number that each section 
addresses is listed in parenthesis after the section name. 



The Interactive Processing Systaa is illustrated in 
figure 2.2. 


3.1 PBOBLEH DISPLAY (2.3.1, 2.3.2) 

’ 1 

To provide the user with the capability to 
display all the element values for a particular problem 
described in section 2.1 of the PDS DSD. The Problem 
Display constitutes a single problem data report. The 
element may be displayed in either Standard Abbreviation or 
Express Code format. 

The Problem Description, Remarks, Analysis, and 
Hesolution text fields will only use as many lines as 
necessary to display the data they contain. The Remarks 
text, will be displayed after Problem Description if the 
complete text will fit on page 1, otherwise Remarks will be 
displayed on page 2. Similarly, the Resolution text field 
will be displayed after Analysis if the complete text will 
fit on page 2, otherwise, the Resolution text field will be 
displayed on page 3. A Continue or paging command will be 
provided to allow the user to direct display of the second 
and third pages. Listed below are the two displays with 
their associated function key that support the above 
function. 

* Standard Problem Display - 01 

• Express Problem Display - 08 

These transactions will consist of the tasks listed 
below. 
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• Input 

• Read Data Base 

• Security 

• Write Terminal 

Each task must provide the linkage through the TLP to 
the next task to be executed, with the last task in the 
sequence returning to the Command transaction. 

Figure 3-1 illustrates the flow of the transaction. 

3.2 PROBLEM ADD (2.5. 2.1) 

Function: To provide the user with the capability of 

entering the element values of a new problem in the problem 
data base. After transmission the input data will be edited 
in accordance with the security checks outlined in section 
2.4 (DRD) and the data edits outlined in section 2.1 (DRD) . 
All errors will be displayed and the originator will have 
the opportunity to make corrections. Assuming page 1 is 
accepted, the originator may then continue to input data on 
page 2 and page 3, transmitting each page and making 
corrections as required sequentially; or he may enter 
another new problem if no data exists for pages 2 and 3, 

The data may be entered in either Standard Abbreviation or 
Express Code format. The transactions that provide this 
capability and their associated function keys are listed 
below. 

• standard Problem Add-Page 1-02 

• Standard Problem Add-Page 2-03 

• Standard Problem Add-Page 3-04 
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• Express Problem Add-Page 1 - 09 

• Express Problem Add-Page 2-10 

• Express Problem Add-Page 3-11 

These transactions will consist of the taslcs listed 
below. 

• Input 

• Read Data Base , 

• Security 

• Write Terminal 

\ 

• Read Terminal 

• Validation 

• Write Data Base 

Each task must provide the linkage through the TLP to 
the next task to be executed. The Command transaction will 
be called at the termination of the transaction. 

• Figure 3-2 illustrates the flow of the transactions. 

3.3 PROBLEM UPDATE (2. 5. 2. 2) 

Func tio n; To provide the user with the capability of 
changing the element values stored in the problem data base. 
The JSC Problem Display, including all current element 
values for the requested problem, will be displayed. The 
user may then proceed to change values in accordance with 
the authorities discussed in section 2.4 (DRD) , transmitting 
the entire page of data. The software will determine the 
changes made and edit all new data in accordance with the 
data element edits outlined in section ‘ 2. 1 (DRD). The data 
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■ay be updated in either Standard Abbreviation or Express 
Code format. The transactions and their associated function 
key that provide this, capability are listed belov. 

• Standard Prob.lem Update-Page 1-05 

• standard Problem Update-Page 2-06 

• standard Problem Update-Page 3-07 

• Express Problem Update-Page 1 - 12 

• Express Problem Update-Page 2-13 

• Express Problem Update-Page 3-14 

• / 

Each transaction will consist of the tasks below. 

• Input 

• Bead Data Base 

• Security 

• Write Terminal 

• Read Terminal 

• Validation 

• Write Data Base 

Each task will provide the linkage through the TLP to 
the next task to be executed. The Command transaction will 
receive control at the end of the transaction. 

Figure 3-3 illustrates the flow of the transactions. 

3.4 CODE LIST DISPLAY (2.3.3) 

F uncti on; To provide the user with the capability to 
display the code tables stored in the current Tables Data 
Base. The user may display a desired code table in two 






1 


ways. First, he can request that thfe entire code list for 
any given table sorted by designated parameter in ascending 
order be displayed. Or he may enter the Express code or the 
Standard Abbreviation Code and have the element definition. 
Standard Abbreviation Code, Express Code, and the other-info 
fields displayed. Two transactions are required to provide 
this capability. They are listed below with their 
associated function key. 

• Code List Table Display - 15 

• Code List Element Display - 16 

t 

Each task will provide the linkage through the TLP to 
the next task to be executed. The Command transaction will 
receive control at the end of the transaction. 

Figure 3-4 illustrates the flow of the transactions. 

3.5 CODE LIST UPDATES (2.3.3) 

F un ct i on: To provide the user (PAE) with the 

capability to update code list entries. Code list changes 
will be applied to the Tables Data Base at the time of 
entry, but will not be used until the following day for 
validation. However, adds will be used for data validation 
upon entry. A batch program will be required to search the 
Problem Data Base each night to update elements effected by 
the code list changes entered for that day. Two 
transactions are needed to provide the above capability. 

They are listed below with their associated function key. 

Code List Element Add - 17 
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Code List Element Update - 18 

These transactions will consist of the following tasks. 

• Input 

• Security 

• Read Data Base 

• Write Terminal 

• Read Terminal 

• Write Data Base 

Input will receive control when these transactions are 
requested. Input will pass control through the TLP to the 
next task in sequence of task. Similarly, each task will 
pass control to the next until the end when Write Data Base 
will pass control back to the Command transaction. 

Figure 3-5 illustrates the flow of these transactions. 

3.6 ABBREVIATED PROBLEM DISPLAY (2.3.4) 

Function; To provide the user with the capability to 
display the values for six significant elements for any 
Project-Problem Report number requested. The six elements 
displayed are Subsystem, Level, Cause, Action Assignee, 
Date/Updated, and Actual Resolution Date. Project, Level, 
and Cause codes will be displayed in Standard Abbreviation. 
This transaction (function key 19) consists of the following 
tasks. 

• Input 

• Read Data Base 
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• Security 

• Write TerminajL 

The tasks are executed in the above sequence with the 
control being passed through the TLP. 

Figure 3-6 illusi:rates the flow of this transaction. 

3.7 ELEMENT DISPLAY’ (2.3.5) 

Fr action; To provide the user with the capability to 
display exactly what value has been entered and stored in 
the data base for an elejneut. The user must enter the 
Project, Problem Report Number, and the specific element 
name. The element will be displayed in both code and 
standard abbreviation value. This transaction (function key 
20) consists of the tasks below. 

• Input 

• Read Data Base 

• Security 

• Write Terminal 

The tasks are executed in the above sequence with 
control linkage being passed through the TLP. 

Figure 3-7 illustrates the flow of the transaction. 

3.8 ELEMENT OPDATE (2. 5. 2. 2) 

Fun ct ion; To provide the user with the capability to 
change the value stored in the data base for an element. 
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Figure 3-6 Abbreviated Problem Display 
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The user will input the Problem Number, Project, element 
name, and new element value. The same security and edits 
checks will be performed as de£>cribed in section 3.3 of this 
document. This transaction (function key 21) consists of 
the tasks below. 

I 

• Input 

• Read Data Base 

• Security 

• Write Terminal 

• Read Terminal 

• Validation 

• Write Data Base 

The tasks are executed in the above sequence with 
control linkage being passed through the TLP. 

Figure 3-8 illustrates the flow of this transaction. 

3.9 GROUP DISPLAYS (2.3.6) 

Func ti on: To provide the user with the capabilty of 

displaying Problem Data base element values from each of the 
major information groups as defined in the DRD for the JSC, 
Shuttle Problem Display. No updates will be allowed from 
this display. The element may be displayed in either the 
Standard Abbreviation or Express code format. The group to 
be displayed is identified by a function key request. 

Listed below are the displays and the associated function 
key. 
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• standard Problea Identification - 22 

• Express Problea Identification - 23 

• Hardware Identification " 24 

• Problem Effectivity - 25 

• Problem Description - 26 

• Standard Pertinent Docuaent - 27 

• Express Pertinent Document - 23 

• Remarks Division - 29 

• Analysis Division - 30 

• Resolution Division - 31 

The user must also identify the project code and 
problem report number. 

The above ten transactions will consist of four tasks 

each: 

• Input 

• Read Data Base 

• Security 

• Write Terminal 

Bach task must provide the linkage through the TIP to 
the next task to be executed, with the last task in the 
sequence returning to the Command transaction. 

Figure 3-9 illustrates the flow of the transactions. 

t 

3.10 ONLINE DISPLAYS (2.3.7) 

FqRct j.o n; To provide the user with the capability to 
retrieve, sort and display data by making direct queries on 









the (iatd stored in the Problem Uata Base, Multiple 
occurrences of a data value can be located by searching 
selected data fields for a specific data value. Or, unique 
occurrences can be identified by the use of the Boolean 
operator *and». 

» 

I 

Element values will be converted to Standard 
Abbreviations where possible. The following Online Displays 
have been identified for PDS. The function key to initiate 
processing is included by the name of the display. 

• PAE Problem Review - 32 

• Open Problem Summary - 33 

• Subsystem Problem - 34 

• Action Assignee-Open - 35 

• Action Assignee-Resolved - 36 

• Part Number Searches - 37 

• Part Name Indices - 38 

The above seven transactions will consist of three 
tasks each: 

• Input 

• Read Data Base 

• Write Terminal 

The input task is designed to call, after it completes 
its function, the Read data base task which subsequently 
calls write terminal. The write terminal task will return 
control to the Command transaction. The above linkage is 
accomplished through the Task Link Processor. 
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Figure 3-10 illustrates the flow of the transactions. 

3.11 PROBLEM DELETE (2. 5. 2.1) 

Function; To provide the user with the capability to 
delete a problem that has not been verified. Verified 
problems cannot be deleted. This transaction consists of 
the following tasks. 

• Input 

• Read Data Base 

• Security 

\ 

• Write Data Base 

» 

This transaction is initiated by function key number 

39. 

Each task must determine which task is to be executed 
next in the task sequence through the TLP. 

Figure 3-11 illustrates the flow of the transaction. 

3.12 SECURITY TRANSACTIONS (2.4) 

Function; To provide PAE with the capability to 
control and assign a user ID and password for each PDS user. 
This includes the capability to change the range of a user's 
access to problems entered in the Problem Data Base. The 
transactions and their associated function keys are listed 
below. 
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• Problem Reassignment - ^0 

• Add Password - 41 

• Change Password - 42 

• Delete Password - 43 

The above transactions require the following tasks for 
execution. 

• Input 

• Head Data Base 

• Security 

• Write Data Base 

Each task must determine which task is to be executed 
next in the task sequence through the TLP. 

Figure 3-12 illustrates the flow of the transactions. 

3.13 SIGN-ON 

Fun ction ; To provide PDS with the capability of 
determining if the user requesting PDS is a valid user. 

This transaction uses the Security data base for this 
validation. Upon validation, the Siga-On transaction 
automatically transfers the user to the Command transaction. 
No function key is required for the Sign-On transaction. 

3.14 SIGN-OFF 

Function: To provide PDS with the capability of 

terminating the user. Involved in this process is the 
recording of all statistical and logging information 
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accumulated during execution of PDS. The function key to 
reguest this transaction has not been defined at this time. 

3.15 COMHAND 

Function: To provide PDS with the capability of 

determining which of the requestable transactions the user 
wishes to execute. It then transfers control to the first 
task in the sequence of tasks to execute the request. 
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4 . 0 MTCH_PRQC£SSrNG SYSTEW 


The Batch Processing System vill consist of six 
programs that produce large volume reports. These programs 
vill generate the reports using PLI/FORTBAN or FORTRAN, The 
specific reports produced are: 

• Open Problem List (OPL) 

• Full Problem Report (FPH) 

• Interactive Problem Transaction Listing 

• Interactive Table Transaction Listing 

• Usage Statistics Report 

• Code Table Listing 

The input required, the processing to be performed for 
the report, and the output generated by the execution of the 
programs is outlined in the DBD for PDS. The paragraph 
number that each program addresses in the PDS DBD is listed 
in parenthesis after each program title. The Batch 
Processing System is illustrated in figure 2'-3, 

4.1 OPEN PROBLEM LIST (2.2.1) 

The function of the OPL is to portray for management 
review the current problem status and other related 
information of all open problems and those problems which 
have been resolved since the date of the last OPL. Through 
user options, print out can be limited to specified 
projects. Also problems can be selected at the system level 
only. Program logic will assure that each resolved problem 
will print once at the element level and once at the system 
level. The order of printing of problems on the oPL will be 



determined by ascending sorts on the PROBLEM REPORT Number 
vithin the SUBSYSTEM cqde within the PROJECT code. At the ! 

end of the OPL, an index/tally will be printed. Figure 4-1 
illustrates the flow of the Open Problem List program. 

4.2 FULL PROBLEM REPORT (2.2.2) 

The function of the Full Problem Report is to print a 
report of all the element values for selected problems in 
the data base. The user will select the problems to be 
printed in the FPR by designating a project and subsystem or 
action assignee and selecting all open problems or all 
closed problems. The order of printing of problems on the 
FPR will be determined by ascending sorts on the PROBLEM 
REPORT Number within the SUBSYSTEM code within the PROJECT 
code. Figure 4-2 illustrates the flow of the Full Problem 
Report program. 

4.3 INTERACTIVE PROBLEM TRANSACTION LISTING (2.2.3) |) 

The function of the Problem Transaction Listing report 
is for verification and chronological recording of all 
changes made to PDS data base. All probleta transactions 
recorded that altered the problem data base during the 
interactive operation for that day will be printed. At the 
end of the transaction listing, a summary table of the total 
number of transactions for each user ID will be printed. 

This report is for the PAE review only* Figure 4-3 

illustrates the flow of the Interactive Problem Transaction 

Listing program. « 
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4.4 INTERACTI7K TABLE TRANSACTION LISTING (2.2.4) 


The function of the Interactive Table Transaction 
Listing report is a chronological recording of all the 
changes made to the Code Tables by PAE. All table 
transactions recorded that altered a code table during a one 
aonth period will be printed. At the conclusion of the 
report, a suamary of the total number of table transactions 
will be printed. This report is for the PAE review only. 
Figure 4-4 illustrates the flow of the Interactive Table 
Transaction Listing program. 

4.5 USAGE STATISTIC REPORT (2.2.5) 

The function of the Usage Statistics Report is to 
optimize system usage and resource availability by listing 
the computer accounting units used, the number of security 
violations incurred, and the number of editing errors 
coamitted by each user. All usage data recorded during a 
one aonth period will be printed. A summary total will be 
printed at the conclusion of the report. This report is for 
the Quality Project Engineering review. Figure 4-5 
illustrates the flow of the Usage Statistics Report program. 

4.6 CODE TABLE LISTING (2.2.6) 

The function of the Code List Report is to present 
either a selected code list or all code lists. The code 
list data printed will be exactly as entered and stored for 
each particular list in the table data base. All users aay 
regye^t this report. Figure 4-6 illustrates the flow of the 
Code Table Listing program. 
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5.0 IMPLEMENTATION 


5.1 DATA BASE ESTABLISHMENT 

Data Base establishnent will require two najor efforts; 
the creation of the data base structures and the conversion 
of the current data in the IPDS data base. 

The data base structure for the PDS will utilize the 
hierarchical structure defined by System 2000. Creation of 
the data base structures will be accomplished through Define 
Module concepts now available under the System 2000 data 
base management system. Figures 2-5 through 2-7 illustrate 
the data base structures for PDS. 

The data for the PDS data bases will consist of the 
data in the IPDS data base. The implementation effort will 
include the generation and testing of software to validate 
and convert the IPDS data base into the format required for 
loading into the PDS data bases. 

The conversion software will consist of a natural 
language command to unload the IPDS data base in loader 
string format. Secondly, each entry will then be edited to 
conform to the PDS specifications for a new problem by a 
PLI/FORTBAN program. Problems will be rejected if they do 
not have acceptable values for the Initial Problem Required 
(IPR) elements. All other elements will retain a null value 
if the value entered in the IPDS data base is unacceptable. 
The user will be notified of all errors and the action taken 
by means of an error report. Also a report of all problems 
accepted will be generated to inform the user of what will 


be in the data base at the initiation of production. This 
report will be available to the user as soon as the 
conversion program is running. Finally, the loader string 
will be reorganized and reformatted into a suitable fornat 
which can be loaded' into the PDS data bases. 
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